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Description 

SYSTEM FOR DEVELOPING DATA COLLECTION 
5 SOFTWARE APPLICATIONS 

Technical Field 

This invention relates generally to software 
development systems, i.e. software development tools, and more 
10 specifically concerns such a software system for developing 
specific data collection software applications. 

Background of the Invention 

Software application development tools and methods 

15 have evolved and improved quite dramatically since their origin. 
Even with the latest software development tools and methods, 
however, it is still difficult to produce a .working data 
collection software application (a computer program concerned 
with data collection) in less than six to nine months. The term 

20 Mata collection application" as used herein refers to a . 
software-based system for acquiring and evaluating information; 
Such applications are used for due diligence investigations, 
internal audits, compliance reviews in various fields, document 
tracking and other applications which involve the collection and 

25 evaluation of data which is in the form of data records. 

The process of producing a new data collection 
application (the software) has in the past typically involved a 
number of skilled people, including a software developer, a 
database administrator and a project lead, as well as test 

30 personnel and resources. With the increased pace of change in 
both the public and private sectors, there is an increasing 
demand for new data collection application software that can be 
developed faster and at less expense than previously. 

Software development in general has taken two 

35 different directions in attempting to keep pace with the 
increased demands for new application specific software. The 
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first line of development is directed toward generating a large 
number of small, individually self-contained applications 
limited to a single data storage system. While this approach 
reduces the software development time for each application, 
5 there are issues, not surprisingly, of data integrity with this 
approach, as well as multiple entry requirement issues and 
possible problems concerning the sharing of data between two or 
more applications. 

While such arrangements are workable in a general 

10 sense, the storage systems for such an approach typically 
include data structures which are not easily changed, and 
further, the overall system requires highly skilled software 
specialists dedicated to maintenance of the software for the 
several applications. Still further, this approach does not 

15 take into account the increasing demand for a rapid change 
capability in a particular data collection application in both 
function and data structure. 

In a second approach, evolving application needs are 
anticipated by creating a data structure which includes every 

20 data element believed to be required by a particular 
application, both now and in the anticipated future. This data 
structure approach usually involves a large number of data 
collection screens by which the large set of data elements are 
captured. This latter approach is generally viewed as quite 

25 cumbersome; further, it does not address the potential 
introduction of new data elements which may require changes to 
existing screens, or changes to existing application "rules", 
guidelines and requirements for the data. 

Hence, there is a need for a different approach to 

30 application software development for data collection 
applications, as well as a need to ensure that the individual 
application structure is sufficiently flexible and adaptable 
that it can be readily modified to meet changes in the 
particular operating conditions and/ or desired functions of the 

35 application. 
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Disclosure of the Invention 

Accordingly, the present invention is a software 
system for developing new computer-based data collection 
applications, comprising: a first software program portion for 
5 developing an information structure which includes information 
covering several components, namely, data elements, data screens 
and rules for processing data and performing calculations 
thereon, said information being supplied by an end user of the 
new data collection application; means for developing and 

10 maintaining data storage for input data which is provided by an 
end user for the data collection application; and a second 
software program portion for interpreting and accessing the 
information structure developed by the first software program 
portion for processing the input data in accordance with the 

15 information structure. 

Brief Description of the Drawings 

Figure 1 is a flow chart showing the overall data 
collection software development system of the present invention. 
20 Figure 2 is a simplified flow chart for a particular 

selected application. 

Figure 3 is a flow chart for one portion of the 
system of Figure 1. 

Figure 4 is a flow chart for another portion of the 
25 system of Figure 1. 

Figure 5 is a flow chart for another portion of the 
system of Figure 1. 

Figure 6, 7, 8 and 9 are interface screens to permit 
the user to define the system portions of Figures 4 and 5 . 
• 30 Figure 10 is a flow chart of another portion of the 

system of Figure 1. 

Figures 11 and 12 are interface screens to permit the 
user to define the system portion of Figure 10. 

Figure 13 is a flow chart for another portion of the 
35 system of Figure 1. 
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Figure 14 is a flow chart for another portion of the 
system of Figure 1. 

Figures 15-17 are interface screens to permit the 
user to define the flow chart of Figure 14. 
5 Figure 18 is a flow chart for another portion of the 

system of Figure 1. 

Figures 19-21 are interface screens to permit the 
user to define the flow chart of Figure 18. 

Figure 22 is a flow chart for another portion of the 
10 system of Figure 1. 

Figures 23-29 are interface screens to permit the 
user to define the flow chart of Figure 22. 

Figure 30 is a flow chart for another portion of the 
system of Figure 1. 
15 Figure 31 is a flow chart for another portion of the 

system of Figure 1. 

Figures 32-36 are flow charts for various portions of 
the second component of the system of the present invention. 

20 Best Mode for Carrying Out the Invention 

The present invention is a software system which 
enables an end user to create custom data collection 
applications without the assistance of a programmer or other 
software professionals. The present system is capable of using 

25 a predefined software structure, pre-existing templates when 
desired, and other system attributes,, with input instructions 
from an end user, to produce new data collection applications 
with defined data fields and data storage, defined data 
collection methodology, multiple level rules governing the 

30 application and defined calculations. 

An example of a typical end user is a lending 
institution which is responsible for overseeing and maintaining 
various loans, including, for instance, residential and 
commercial loans, or for overseeing the operation/cash flow of 

35 real estate properties. Other examples of end users and 
specific data collection applications include medical offices, 
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for collecting and monitoring information for medical claims; 
any of numerous organizations which require inventory control 
systems; and non-profit organizations, for maintaining and 
analyzing information concerning donors. 
5 It should be emphasized that the above examples of 

end user institutions and the specific data collection 
application examples related thereto are for illustration of the 
present system disclosed herein, and should not be considered to 
be limiting relative to the scope of the invention. 

10 As indicated above, when end users have in the past 

had a need for a new custom data collection application, 
involvement of information service professionals was always 
necessary. Program specifications were required, actual program 
code corresponding to the specifications had to be written, and 

15 data base formation and management had to be accomplished. 
Further, the completed program had to be thoroughly tested. 
This would frequently require both considerable time (typically, 
6-9 months) and expense. In addition, the completed system had 
to be maintained by experienced technical personnel. 

20 The present invention involves a substantially 

different approach to development of new data collection 
applications. The system, for purposes of ease of explanation, 
comprises two major components . The two major components are 
software development applications/tools which are used together 

25 (1) to define (build) a basic data collection application 
structure in accordance with instructions from the end user 
through the use of predefined screens, (2) to enable editing of 
that basic structure and (3) to provide an ability for the end 
user to input data, which is first stored and then analyzed 

30 (including the use of calculation steps) by the completed new 
application. 

One important aspect of the data collection 
application development system of the present invention is that 
no new software code is produced for the new data collection 
35 application. Rather, the functions of the new application, 
which are defined by the user in response to the interface 
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screens provided by the development system, are carried out by 
the development system itself. The information obtained from 
the user's response to the interface screens produces a custom 
application structure within the development system for carrying 
5 out the specified functions of the new application in accordance 
with the end user's input information. 

The first major component of the system of the 
present invention, referred to as the builder (or building) 
component, functions to produce the basic structure for new 

10 data collection applications. Briefly, this n building" 

component, involving information provided by the user, includes 
the selection and definition of data elements for the new 
application, development of various screens for the new 
application, development of applicable rules concerning 

15 calculations and requirements for the input data matrices which 
define specifications and guidelines for consideration and 
analysis of the input data, and development of reports 
concerning the actual outcome (results) of the data collection 
application. Again, the information used by the building 

20 component of the system to produce the new data collection 
application is provided by the end user. 

The second major component of the system of the 
present invention, referred to as the run- time component, 
interprets the information gathered and structured by the first 

25 portion, and further includes the ability of the end user to 
modify or edit the structure of the new application, after it 
has been created, as well as the ability to enter actual input 
data for the new application. 

Figure 1 shows the overall system of the present 

30 invention and the interaction between the system builder 
component 12 and the system run-time component 14. The two 
components may be on separate servers, with the system builder 
component 12 being located on a centralized server, while the 
system run-time component 14 is located at the facility of the 

35 end user. The two components could also be on a single server. 
Basically, the system building component 12 gathers information 
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from the end user by a series of screens to produce what is 
known as metadata, i.e. information concerning data. This 
metadata in turn is collected and stored in a data dictionary- 
database, in the form of information tables. 
5 The system builder component 12 is responsible for 

producing the data dictionary database, including creating the 
information tables therein, from information provided by the end 
- user. The system builder component 12 is capable of creating, 
adding to or removing fields from existing screen templates and 

10 creating new screens to produce the new application. The 
information provided by the user, generalized for field 
information but intended to include all user-provided 
information, at block 10, is used by the system builder 
component 12 to produce appropriate corresponding metadata, as 

15 shown in block 14, which is ultimately stored as part of a data 
dictionary. 

There are three major structural portions in a new 
data collection application developed by . the present invention. 
First, the system building component, through information 

20 provided by the end user, includes a definition of the data 
elements which are the basis of the new application, including 
the type of input data, the size and name of the data, the 
assigned data table, and the look-up codes for the data. In 
essence, this portion defines the characteristics and format of 

25 the data fields which are the focus of the new application (e.g. 
residential loan records in a lending institution)*. The data 
elements portion includes all of the defining information 
concerning the data for the new application. This is 
represented at block 18. 

30 A second major portion of the new data collection 

application structure produced by the system builder component 
12 concerns the screens available to the user for the new 
application. This is represented at block 20. Information 
provided by the user about the screens to be provided in the new 

35 application specifically includes the layout, order and other 
information concerning the screens themselves, as opposed to the 
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data on the screens. The number of screens and the particular 
information provided on each screen can vary from application to 
application, depending upon the user's requirements. It is the 
user who defines the details of the screens for the new 
5 application. 

The third major portion of the new data collection 
application is shown by block 24 and concerns what is referred 
to in this application as u business rules". "Business rules" 
involve specific calculations, edit functions and industry- 

10 specific requirements which affect the evaluation of the data in 
the new application. For instance, in evaluating particular 
mortgage loans, there will be rules involving the evaluation and 
analysis of individual mortgages. Examples of such rules, on 
the record-level, relative to residential home loans, might 

15 include the following: (1) if the record being evaluated is a 
first mortgage, then there cannot be anything indicated to be 
superior to the first mortgage; and (2) if the record concerns 
purchase of a residential property, the w sales price" portion of 
the record cannot be zero. Again, it is the end user who 

20 defines the particular rules which are used for the new data 
collection application being created. 

Other portions of the application structure produced 
by the system builder component 12 include regulatory 
compliance information, what is referred to as matrix 

25 specification information, and finally, report information. 
These additional portions of the present system will be 
discussed below when all of the individual portions of the 
application are discussed in detail. 

The system builder component 12 takes all of. the 

30 information concerning the above-described individual portions 
or aspects, and collects them in a database, referred to as a 
data dictionary, shown at block 26. It should be understood 
that the information in data dictionary 26, which defines the 
structure of the new data collection application, does not 

35 contain any new programming code for the new application per se, 
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but rather information provided by the end user organized into 
tables. The tables actually define the new application. 

The system builder component 12 also organizes a data 
collection database, shown generally as block 30. The data 
5 collection database 30 is for the storage of actual input 
information which is collected and then processed by the new 
application. The input data is entered, as indicated above, by 
the end user. 

The second component 14 of the present system 

10 concerns the execution of the new data collection application 
produced, i.e. built, by the system builder component 12. The 
system run-time component 14 includes the ability to change or 
edit the various portions of the structure produced by the 
system builder component 12, as well as interpreting, i.e. 

15 processing, the metadata information in the data dictionary 26 
relative to the input data. In the present system, there are 
limitations on the run-time component 14 relative to the new 
application structure produced by the system builder component. 
For instance, the run- time component cannot change the basic 

20 structure of the data element and screen portions 18 and 20, 
although some editing functions are permitted. 

Basically, as shown in Figure 1, the system run- time 
component 14 interacts with the data dictionary 26, with 
information from the user, as indicated generally at 32, to 

25 change (edit) selected data field information (block 34), to 
collect input data, verify existing system rules and run certain 
calculations (block 36) and to change the various possible 
calculations performed on the input data, the algorithms and the 
rules (block 38) . 

30 Hence, in the particular embodiment shown, the run- 

time component 14 has a rather limited possible effect on the 
basic application structure produced by the system builder 
component 12, but has the execution responsibility concerning 
the input data provided by the end user, including manipulating 

35 and analyzing the data, as well as performing various 
calculations on the data. Further, it has a limited ability to 
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affect the structure of certain aspects of the application. It 
is possible, however, in variations of the present system, for 
the system run-time component to have a somewhat different 
functional capability relative to the application structure, 
5 i.e. the capability of the run-time component to affect the 
structure produced by the system builder component can be 
varied, in particular it can be enhanced, if desired. 

Referring now to Figure 3, the system builder 
component 12 includes the ability to create an entirely new data 

10 collection application (referred to as a data tool), as shown at 
block 40, or to edit an existing data collection application 
(data tool), as shown at block 42. In creating an entirely new 
application, new data elements are defined, as shown at block 
44; screen layouts are either defined or selected, as shown at 

15 block 46; business rules are defined or selected as shown at 
block 48; regulatory compliance rules are defined or selected as 
shown at block 50; optimization and other matrix functions are 
defined or selected as shown at block 52; and reports are 
defined or selected as shown at block 54. 

20 The same functions are carried out when an existing 

data collection application of the end user is to be changed, 
i.e. edited. The present system thus has the advantage to the 
end user of not only being able to create new data collection 
applications to meet new requirements, but also to edit existing 

25 applications. The information provided in response to screens 
for blocks 44, 46, 48, 50, 52 and 54 is then converted into 
corresponding information tables in the form of metadata, 
including data field information tables 45, screen information 
tables 47, record-level rule tables 49, regulatory compliance 

30 information tables 51, matrix information tables 53 and report 
information tables 55, which then are used to form the database 
dictionary 26. 

Figure 4 is a detailed flow chart for the system 
builder component 12 relative to creating /editing the data 

35 elements of the application structure, in response to specific 
input from the end user. In dealing with data elements, either 
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a new data element field can be created as shown at block 60, or 
an existing data element field can be edited, as shown at block 
62. In creating a new data field, a new table may be created, 
the field may be added to an existing table, a name for the new 
5 data field can be produced, the language for the data field can 
be selected and the data field type can be chosen, as shown at 
blocks 64, 66, 68 and 70. 

In defining the table for the new data element field 
(block 64) , the type of new table (if a new table is to be 

10 created) can be defined, as shown at block 72 . It should be 
noted that the functions of block 68 and 70 can only be 
accomplished by the user with respect to new data fields; such 
functions for existing data fields cannot be changed by the 
user. Following the selection of the field language (block 68), 

15 e.g. English, French, German, etc., a selection of a particular 
prompt for use on the screen and the xx help" text for the data 
field is made by the user, as shown at blocks 74 and 76. 
Separate prompt and help texts can be used for each language. 

For the field type block 70, the format for the field 

20 on the screen can be selected (block 78) , as well as the field 
size (block 80) and the number of decimals if the data element 
is in numeric form (block 82). Of the various instructions 
provided in Figure 4, data elements which may be * imported", 
i.e. obtained u as is" from an existing application, can be 

25 edited except for the data element name and the table to which 
it belongs. 

All of the information described in Figure 4 in the 
various blocks is provided by the user and then established in 
data field information tables (block 45) and then placed into 

30 data dictionary database 26. 

Figure 5 shows additional flow chart information for 
the data elements, i.e. it is an addition to Figure 4. 
Referring to Figure 5, information concerning the field rules 
(block . 88) , the particular calculation to be stored in the 

35 fields (block 90), special field functions (block 92) and look- 
up codes (block 94) can be defined by the user, both for 
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creating new data elements and editing existing ones. Under the 
field rules, the range of the field (95) , whether or not the 
field can be allowed to be empty (96) , whether or not there are 
any limitations on the field value (97) and business rules 
5 affecting the field (102) can all be provided by the user. All 
of this information is produced in the form of data field 
information tables in the data dictionary 26. Information 
concerning field calculations, meaning the numerical 
calculations which are accomplished on the data elements, can be 

10 . provided as set forth in block 90. This information appears in 
field rules tables 101 of the system structure. 

Special field functions (block 92) include 
information indicating that the field itself is not changeable 
under certain specified conditions (block 104) , and information 

15 indicating a read-only function for the field (block 106) . The 
information from block 104 is applied to rules tables 101, while 
read-only information is applied to data field information 
tables 45 . Look-up code information is included as part of the 
data field information tables for both new fields and for 

20 existing fields. 

Figures 6, 7, 8 and 9 are interface screens for the 
end user to provide instructions for the system builder 
component 12 relative to the creation or editing of data 
elements shown in Figures 4 and 5 for the new or existing 

25 application of . the user. These interfaces are believed to be 
self-explanatory, and therefore are not described in detail. 

Figure 10 is a flow chart in which the system builder 
component 12 of the present system is used to define the 
structure for the data collection screens. The definition of 

30 the data collection screens is again accomplished in accordance 
with instructions from the end user. The system builder 
component 12 has the capability of creating new screens (block 
108) or importing screens from another application (block 110) 
for a new data collection application. System builder component 

35 12 also has the capability of editing screens in an existing 
data collection application, shown at block 112. 
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With respect to blocks 108 and 112, several 
information capabilities are provided, including the assignment 
of the screen to a particular set/category (block 114) , the 
selection of the location of the fields in the particular screen 
5 (116), the creation of labels for the screens (118) and the 
definition of special functions of the screens. 

The information concerning the screen set/category 
provided by the user is incorporated in the screen information 
tables, as well as the XML (extensible mark-up language) 

10 document (block 129) through block 116- Relative to block 116, 
information concerning the selection of the location of the 
screen fields can be obtained from another data dictionary in 
another, existing application (block 124) ; or it could be an 
entirely new selection of fields (block 125) , developed in 

15 accordance with the process shown in Figure 4, or it could be 
from the current data dictionary, i.e. from hlock 126. 

The user then "drags" the selected or created field 
onto the screen, as shown in block 117. The system builder 
component 12 then reads the properties of the field from the 

20 data field tables, as shown in block 119, and then actually 
produces the custom field on the screen, based upon the 
information previously provided by the user, as shown at block 
121. The user then goes further, establishing the actual format 
of the fields on the screen, including the alignment, the 

25 particular font, color, etc., as shown in block 123. The user 
will then see a "screen complete" prompt, which requires a 
decision (block 127) . If the answer is no, the program reverts, 
i.e. loops back, to block 116 for the next field. This process 
continues until all the fields in the screen are complete, at 

30 which point the system creates an XML document for the 
particular screen, based on the created fields, including the 
field properties and the controls. This is represented in block 
129. The XML document information will then be provided for the 
screen information tables, represented at block 47. 

35 The user has the opportunity to set the format for 

the labels for each screen (block 118), including the particular 
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font, color, alignment, etc. From there, the screen complete 
prompt (block 127) is shown to the user. If all the labels in 
the screen are not complete, the program reverts back to block 
118 until all labels are completed. 
5 For the special function instructions for the 

screens, the end user can provide either (1) special pop-up 
instructions following the occurrence of a particular condition, 
or (2) provide that the screen disappear under particular 
conditions. This information is represented by blocks 130 and 
10 132, respectively. The information from these blocks is 
supplied to the rules tables for the screen. The interface for 
defining a new screen or editing an existing screen is shown in 
Figure 11. 

Referring still to Figure 10, importing an entire 

15 screen from another data dictionary is an important capability 
of the system builder component of the present invention, as it 
enables a user to very quickly provide a significant data 
collection capability/function without substantial time and 
effort. When a screen is imported from another dictionary, the 

20 system builder component 12 will import not only the screen 
itself,- but will also include all the fields and their attendant 
calculations, rules and look-up codes. 

This is shown clearly in Figure 10. First, at block 
131, the selection of particular screens to import from another 

25 application is made. The user, after the selection, drags the 
selected screens and w drops" the screen on the appropriate 
screen set, as shown at block 133. The system builder component 
12 then reads the screen information tables in the other 
selected application and imports the screen XML and other 

30 information from that application. That information is then 
applied to the screen information tables 45 . The reading of the 
screen and the importing of the information is represented at 
block 135. The system builder component also reads the data 
field tables in the selected application for particular fields 

35 which appear in the screen XML and imports all the field 
information defined in the process shown in Figure 4. 
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The system builder component will also then read all 
the rules /calculations in the selected application for those 
fields which appear in the screen XML, and imports those rules 
and calculations into the new application information structure. 
5 This is shown at 139- The information is then entered in rules 
tables- Figure 12 shows the interface screen for importing an 
existing screen into the new application. 

In a conventional processing system, field 
information cannot be imported from another application. 

10 However, in the present system, as described above, existing 
screens may be imported from other applications and put into the 
metadata data base for the new application, without the need for 
special programming assistance, i.e. the end user is capable of 
providing sufficient instructions in order to accomplish the 

15 desired result. 

Figure 13 shows the flow chart for creating record- 
level business rules for the new application. Other business 
rules, in the form of calculation rules and field level rules 
and the interfaces associated therewith are accounted for 

20 elsewhere. Figure 13 concerns rules which involve multiple 
fields; hence, the term record-level rules, since a data record 
will have several fields. 

Examples of record-level rules for a residential 
loan, for instance, concern such issues as modification of 

25 existing loans or the relationship of the date of the loan to 
the first payment. These affect several fields within the 
record. The end user through the system builder component 12 
can add to, change or delete the various record-level rules. 

In Figure 13, blocks 134 and 136 refer, respectively, 

3 0 to the creation of a new record-level rule and the editing of an 
existing rule in a current application, again by the end user 
supplying information. From block 134, the rule can be both 
named and described (block 139). From there, the actual 
expression of the rule can be defined, in block 140; the error 

35 message which is displayed when the conditions of the rule are 
met (violated) is shown in block 141, and the ability to define 
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the conditions under which the rule may be overridden is shown 
by block 142. The information provided by the user through 
blocks 140, 141 and 142 is incorporated as record-level rules in 
block 49. In the standard software development system, these 
5 record-level rules would be written into code, defined and/ or 
changed by the software developer. In the present invention, 
this is accomplished by end user instructions. 

In many industries, there are issues concerning 
compliance with government regulations. The system builder 

10 component 12 has the ability to provide compliance evaluation 
and review relative to such regulations, with 
instructions /guidance from the end user. This is shown in 
Figure 14. Figure 14 allows the end user to provide information 
which defines both legal (statutory) and regulatory (rules) 

15 requirements of federal and state agencies. Figure 14 refers to 
both as simply rules or requirements. The requirements can be 
grouped to represent licensing regulations or can represent 
specific statutes, such as truth- in- lending laws. The new 
application, by' applying the information/question "tree" of 

20 Figure 14 provided by the end user, can evaluate whether the 
information in the data record (the input data) complies with 
applicable statutes and/ or regulations. 

In Figure 14, the user can enter a new compliance 
rule (block 150) , if a new statute or regulation is applicable, 

25 or modify (change) an existing compliance rule, if an applicable 
statute or regulation happens to change (block 152) . Both of 
these possibilities use the same follow-on tree of 
questions/information established by the end user to determine 
compliance. First, the appropriate regulatory authority is 

30 identified by the user, in block 154. Next, in block 156, the 
precise license or regulation is defined/ edited which determines 
whether or not a particular data record falls under the specific 
regulation or requirement. 

In block 157, the actual step-by-step requirements to 

35 satisfy the particular regulation or statute are established, 
while in block 158, the effective date and/or the expiration 
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date for each regulation/requirement is established. From 
there, the rules for each regulation and the particular 
questions necessary to establish compliance are entered (block 
160), while in block 162, the determination criteria concerning 
5 whether or not the particular record is compliant or non- 
compliant with the regulation are provided. The compliance 
information is included in the compliance information tables 51 
of the dictionary data base. 

Figures 15, 16 and 17 show interface screens by means 
10 of which necessary information concerning compliance with 
applicable regulations and/ or statutory requirements for the 
particular data collection application can be obtained from the 
end user. 

Figure 18 shows the flow chart for building a matrix 

15 (set) of specifications for the data records of the new 
application. An example of such a matrix of specifications 
would be a series of lending guidelines for a data collection 
application involving mortgage financing. In a manufacturing 
data collection application, the matrix could be a grading 

20 specification for parts. 

Referring to Figure 18, a new matrix of 
specifications can be created (block 166) , or a matrix from an 
existing application can be edited (block 168) . From block 166, 
information concerning the name and description of the new 

25 matrix of specifications is provided by the user, as set forth 
at block 170. A decision point is provided at block 172 as to 
whether a particular record is to be evaluated against this 
particular matrix. From that point, the rules and the results 
of the matrix are defined by the end user or edited (block 174) . 

30 At block 176, the conditions for overriding the matrix 
specification are provided. 

The information for this particular matrix of 
specifications is provided to matrix information tables of the 
metadata dictionary, as indicated at block 53. Also, from block 

35 176, the program loops back to a decision block at 178 to 
ascertain from the user whether there are additional matrices to 
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be identified and composed. If there are, then the steps of 
blocks 170, 172, 174, 176 and 53 are repeated for that 
additional matrix. This continues until the user indicates that 
there are no additional matrices to be defined. 
5 The information requested following the edit 

selection at block 168 includes first the selection of the 
particular matrix in an existing application to be edited, as 
shown by block 180. From there, the information steps shown in 
blocks 172, 174, 176 and 53 are the same as for the creation of 

10 a new matrix. In a standard system, the software developer 
would change and define the matrix functionality for new and 
edited matrixes. The interface screens for defining the matrix 
in the embodiment shown are shown in Figures 19, 20 and 21. 

In the embodiment shown, the next operational 

15 function for the system builder component 12 concerns the system 
reports, as shown in Figure 22. The end user can create new 
reports, import reports from an existing dictionary in another 
application into the new application, or edit (change) the 
characteristics of reports in an existing application or the 

20 imported reports. These functions are represented by blocks 
182, 184 and 186, respectively. With respect to importing 
existing reports from existing applications, the user first 
selects the data dictionary source (another application) for the 
report (block 188) and then selects the particular report (s) to 

25 import (block 190) The imported reports will include all of the 
metadata attributes associated with those particular reports in 
the existing application. The report XML (extensible mark-up 
language) and the format information for the imported report are 
read by the system builder 12, as is the field information for 

30 the fields in the report XML. All the field information is then 
imported by the system builder and is entered into the data 
field information tables 45 and the report information tables 
55. 

The user may, as indicated above, also provide 
35 information to create a new report for the new application. The 
creation of a new report may be done in one of two ways. One is 
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by virtue of a tt report wizard'' function, shown at block 194 , 
which takes the end user through a sequence of selecting fields, 
ordering records, grouping records, defining totals and setting 
criteria for the record. The other method, indicated at block 
5 198, is a conventional report writing component (referred to 
generally as a banded report writer) which arranges particular 
reports with preselected features in the report template in 
building component 12. In both cases, the fields, captions, 
particular calculations, headings, etc. which define the report 

10 are established by the end user. This is shown at block 200. 
This inf ormation is then entered in the report information 
tables 55 of the data dictionary. 

Editing of an existing report (of an existing 
application or an imported report) requires use of the same 

15 report functions (blocks 194 or 198). For editing, the user 
selects the particular report to edit, and the system builder 
component 12 opens the particular interface in which the report 
was originally created so that it can then be edited by the 
user. The interface screens for the report wizard are shown in 

20 Figures 23-28. Figure 29 shows an interface screen for editing 
a report using the conventional report builder component. 

The ability to create new reports with information 
provided by the user is quite significant, as in a standard 
system, there is no ability for the user to create new reports 

25 and integrate them into a new application or to import reports 
from another application into a new application. 

When the user has finished defining or editing the. 
metadata forming the data dictionary, the data collection 
database must be built. The user can elect to construct an 

30 entirely new database for the new application, or modify the 
structure of an existing database, which maintains any data 
currently resident in the tables of that database. This is 
desirable where there is a correlation between an existing 
database and the new application. 

35 Referring to Figure 30, the system builder component 

12 is first instructed by the user to create or modify the data 
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collection database. This is shown in block 201. Using the 
data field information tables, as defined by the user, the 
system builder component 12 then determines the complete set of 
data tables required for the new application .and assigns data 
5 elements and their attendant attributes, i.e. characteristics, 
to each table, as shown in blocks 203, 204 and 206, 
respectively. From this information, the data collection 
database itself is created (block 208) . The various information 
tables comprising the database, including the relationships 

10 between the data and the data elements, are then created to 
produce the final data collection database, referred to at block 
30. In a standard system, the creation of and/ or modifications 
of a database structure is generally done manually by a skilled 
database administrator. 

15 Figure 31 shows the final step for the user in 

creating or editing a new data collection application by the 
system builder component 12 . In this portion of the system, the 
system builder component 12 verifies that all required fields, 
i.e. those fields for calculations, rules, screens, reports, 

20 etc. with their attendant look-up codes, are all present, that 
all components required for any special screen or field 
functions are included, and further, that the data collection 
database structure reflects the user-provided metadata for the 
fields and tables required. 

25 In Figure 31, the end user will first instruct the 

system builder component 12 to verify the new data collection 
application, i.e. all of the information/ instructions which have 
been made during the building of the new application. This is 
shown in block 216. From there, the system builder component 

30 will review the metadata (block 218) , specifically all of the 
metadata fields, including the data field information tables, 
the screen information tables, the record-level rule information 
tables, the regulatory compliance information tables, the matrix 
information tables and the report information tables, all 

35 identified as a group at 219. The system builder component 12 
will then check both the data collection database and the data 
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dictionary for completeness so that it can make any necessary 
modifications thereto, as shown in block 220. The application 
data dictionary 26 and the data collection database 30 are then 
modified, as required. 
5 Figure 2 shows a simplified sequence of steps to 

create a new data collection application, referred to as a new 
project (block 221) . Again, this is all user-provided 
information which will appear in metadata form. Examples of a 
new data collection application include mortgage record analysis 

10 and a document tracking system, among many others, A new field 
is created with name, table location, description, prompt and 
other information, as shown in block 222 . Look-up codes are 
determined at block 224 and then are entered, as well as their 
description at block 225. 

15 Next, it is determined whether any calculations are 

necessary within the application (block 228) . If calculations 
are necessary, then the type of user interface and the 
particular calculation required are selected, as shown at block 
230. The requirement for field level rules, if any, is then 

20 determined and the condition is defined as well as the error 
message for the rule, at blocks 232 and 234. Screen designs are 
then made accordingly, as shown by block 236. New and/ or 
existing fields are dragged onto the screen design. 

Pop-up screens, if any, are then identified and their 

25 conditions, at blocks 238 and 240. Next, the conditions, if 
any, under which the screen is to be disabled are determined, at 
blocks 242 and 243. The same determination is made for 
particular fields, as shown at blocks 244 and 245. Next, a 
determination is made as to whether particular field data, look- 

30 up codes, etc. need to be imported into the tables for the data 
collection application. If so, the importing is made, as 
indicated at blocks 246 and 247. The data fields and look-up 
codes are mapped and data is brought into the database. 

Next, data collection tables are created or the 

35 entire application is verified (Figure 31) . The data is then 
loaded, either in wholesale fashion or selectively, as desired. 
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The data is loaded with options and/ or updates. These steps are 
shown at blocks 250 and 252- When the desired data is all 
loaded, the process is complete. 

The screens for the new application must also be 
5 selected by the user (block 253) and the dictionary in another 
application must be selected for import into the new application 
(block 254) if, in fact, a screen is to be imported. The 
selected and imported screens are "dragged" into the application 
structure (block 256) . Any necessary changes to the screens are 

10 accomplished (258) . Information about the screens, referred to 
in blocks 238-245, is then requested and the functions of blocks 
246-252 are accomplished. This completes a simple process for a 
particulax new application. 

Figures 32-36 show the second component of the system 

15 of the present invention, i.e. the system run-time component 
portion 14 which is present at the end user's site. This 
portion of the system interprets the metadata stored in the data 
dictionary so as to properly process the input data in 
accordance with the user's instructions, i.e. collecting, 

20 evaluating and analyzing the input data in accordance with the 
metadata provisions and rules. In the embodiment shown, the 
run-time component 14 itself has a certain amount of capability 
relative to adding or modifying existing business rules or 
reports. Changes to the data and screen structures can only be 

25 made via the system building component 12 in the embodiment 
shown, although it should be understood that this characteristic 
of the system could be changed. 

Figure 32 shows an overall summary of the run-time 
component. In the run-time component 14, selected properties 

30 (characteristics) of the data elements can be changed, as shown 
in block 260; data can be collected, calculations made and input 
data records analyzed in accordance with the various business 
rules in block 262; record-level business rules can be changed 
at block 264; regulatory compliance rules can be changed at 

35 block 266; matrix specifications can be changed at block 268; 
and reports can be modified at block 270. 



WO 01/88703 



PCT/US01/15740 



23 

Still referring to Figure 32, but also referring to 
Figure 3, the information in block 260 affects the data field 
information tables and the screen information tables, while the 
information from block 262 affects the data field information 
5 tables, the screen information tables, the record-level rule 
tables, the regulatory compliance information tables and the 
matrix information tables. Changes to record level business 
rules (264), regulatory compliance rules (266), matrix 
information (268) and reports (270) affect their corresponding 

10 information tables. All of the above individual tables form 
part of the data collection tables (283) which form the data 
collection database (30 in Figure 1) . 

As discussed above, a primary function of the run- 
time component 14 is to permit entry of specific data (input 

15 data) , in the form of records, such as information concerning a 
particular residential loan, and then to run the analyses and 
calculations involving the various business rules and compliance 
requirements relative to that record. However, as discussed 
above for Figure 32, the run- time component also has, in the 

20 embodiment shown, the ability to make certain changes in the 
actual structure of the data collection application. This 
includes the ability to change certain attributes of the 
existing data elements, although new data elements cannot be 
added or deleted by the run-time component. 

25 Figure 33 shows the changes which are possible to the 

data elements by the run- time component. First, the particular 
data field to be changed/ edited is identified, as shown in block 
284. The various options available include selecting the 
language, modifying the field rules, modifying the field 

30 calculations, defining special field functions and establishing 
look-up codes, as shown at blocks 286-290. The modification 
capability for each of those possible categories of change is 
similar to that shown for similar categories in Figures 4 and 5 
for the system builder component. 

35 Figure 34 shows the flow chart of that portion of the 

run-time component which permits changes in the record-level 
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rules. New record-level rules can be created as well as editing 
of existing rules, as shown at blocks 300 and 302. The 
information required for the end user to accomplish the new 
rules and the editing of existing rules is similar to Figure 13 
5 for the system builder component. 

With the run- time component 14, new compliance rules 
can be created or existing rules changed. The procedure is the 
same for that shown in Figure 14 for the system builder 
component. The same is true for the functions of creating a new 

10 matrix of specifications and/ or editing an existing matrix, 
which is shown in Figure 18. 

In Figure 35, existing reports may be edited or new 
reports created by the run-time component 14 at the user's 
facility. This is represented at blocks 310 and 312. The 

15 reports can be edited or created using a report wizard, block 
314, or a report builder, block 316. These were explained above 
relative to Figure 22 for the system builder component 12. 

The report wizard and the report builder both define 
the edit fields, captions, calculations, groupings and headings 

20 for the report, as shown at block 318. The report tables 
receive this information. The run-time component 14 cannot, 
however, in the embodiment shown, import existing reports from 
other applications, although it could be easily modified to 
permit such a function. 

25 Figure 36 shows the application of the metadata 

tables (blocks 45, 47, 49, 51, 53 and 55) relative to the actual 
input data provided by the end user . Specifically, with the 
run- time component 14, the display screen can be loaded (block 
320), calculated fields can be refreshed (block 322), fields can 

30 be displayed or hidden upon certain conditions (block 324) , and 
field rules and record-level rules can both be checked (block 
326) . The matrices can be applied to the input data records as 
can the regulatory rules (blocks 328 and 330) , while specified 
reports can be printed in block 332. 

35 Information to perform the actions in block 320 is 

obtained from the screen information tables (47) ; information to 
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perform the actions in block 322 is obtained from the data 
information tables (45) ; information to perform the actions in 
block 324 is obtained from the screen information tables (47) 
and the data field information tables (45) ; information to 
5 perform the actions in block 326 is obtained from the data field 
information tables (45) and the various rules tables, while 
information to perform the actions in blocks 328, 330 and 322, 
respectively, is obtained from the various rules tables (for 
both 328 and 330) and the report information tables (55). All 

10 the blocks perform the stated actions on data records stored in 
the data collection tables. 

One particular feature of the present invention 
concerns the XML document. Input screens in the present system 
are stored in the form of XML documents and their associated 

15 components (i.e. schemas, XSL style components, etc.). The 
system builder component 12 uses a visual interface to assist 
the user in creating/ editing the XML document and its associated 
components . 

When creating a new input screen, the system builder 

20 12 presents a form that looks like a blank input screen. The 
user can select data elements from the current application or 
from another system builder application. To add a data element 
to the screen, the user simply locates the element from the list 
available and drags it onto the form for the document. The 

25 system builder 12 reads the various properties of the element 
from the dictionary (size, types, whether it has look-up codes, 
whether it involves calculation, etc.), displays the appropriate 
data entry control (combo box for fields with look-up codes, 
date box for date fields, etc.) in the location indicated by the 

30 user, and adds to the XML documents the appropriate tags for the 
data element, its location on the form, its associated control, 
and its properties. When the resulting input screen design is 
saved, the system builder 12 stores the XML document in. the 
screens tables in the data dictionary. 

35 In editing an existing input screen, the system 

builder 12 opens the XML document from the screens table in the 



WO 01/88703 



PCT/US01/15740 



26 

data dictionary and parses it for display as an input screen in 
the design form. The user then can add fields (from this or 
another system builder application) , delete fields, modify field 
properties, etc. The system builder 12 captures the changes and 
5 makes the required modifications to the tags and values in the 
XML document, schema, XSL, etc. When the resulting edited input 
screen design is saved, system builder 12 stores the XML 
document on the screens table in the dictionary. 

The run-time component 14 displays the input screen 

10 by parsing the XML document and displaying it, based on the tags 
and properties contained in the XML document. 

This completes the description of the present system, 
which is capable of producing new custom data collection 
applications for an end user, without the necessity of having to 

15 generate new code for each new application. The system is 
divided into two basic components, one a system building 
component, the other a system run- time component. The system 
uses input information from the end user to develop what is 
known as metadata, i.e. information about data, which is stored 

20 in a data dictionary database. Relevant input data for the new 
application is provided to the run-time component by the end 
user and the data is processed by the run-time component in 
accordance with the processing structure established by the 
system building component. 

25 The input data provided by the end user is stored in 

a data collection database. The processing structure, including 
the data elements, the screens, the compliance and matrix rules, 
and the report structure are all established through end user 
input information, by the system building component. The end 

30 user information is provided to the system building component 
through the use of interface screens and related prompts. 
Existing application structure can be edited both through the 
system building component and the system run-time component. 

Although a preferred embodiment has been disclosed 

35 for purposes of illustration, it should be understood that 
various changes, modifications and substitutions may be made to 
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the invention without departing from the spirit thereof, which 
is defined by the claims which follow: 
What is claimed is: 
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1. A software system for developing new computer-based 
data collection applications comprising: 

a first software program portion for developing an 
information structure for a selected new data collection 
application, the information structure including information 
concerning several components thereof which include data elements, 
data screens and rules for processing data and performing 
calculations thereon, said information being supplied by an end user 
of the data collection application; 

means for developing and maintaining data storage for 
input data which is provided by an end user for the data collection 
appl i ca t i on ; and 

a second software program portion for interpreting and 
accessing the information structure for processing the input data in 
accordance with the information structure. 

2. A system of claim 1, wherein the second software 
program has the capability of modifying selected characteristics of 
the information structure in accordance with the end-user's 
instructions. 

3. A system of claim 1, wherein the components further 
include (1) information about compliance with legal requirements, 
(2) matrix information which includes standards concerning the 
application of the data, and (3) information concerning the form and 
content of reports for the new application. 

4. A system of claim 1, wherein the information 
structure is in the form of metadata stored in a data dictionary 
portion of the information structure, the data dictionary comprising 
information provided by the end user which is thereafter accessible 
to the end user for selected modification. 
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5. A system of claim 1, wherein the first program 
portion includes the capability of creating new definitions of 
portions of the information structure components as well as 
modifying existing definitions thereof. 

6. A system of claim 5, wherein the first program 
portion includes the capability of adding to at least one 
information structure component of the new application information 
imported from another application. 

7. A system of claim 1, wherein the processing rules 
include field-level rules and record-level rules. 

8. A system of claim 3, wherein the matrix information 
includes guideline information against which the input data is 
compared. 

9. A system of claim 2, wherein the second program 
portion includes the capability of editing the existing data 
elements and data screens but is not capable of adding new data 
elements or screens to the information structure. 

10. A system of claim 3, wherein the first program 
portion includes the capability of creating new reports for the data 
collection application, editing existing reports and storing said 
reports as metadata. 

11. A system of claim 1, wherein the first program 
portion has the capability of affecting a plurality of 
characteristics of the data elements, including information about 
the fields, the field rules and the field calculations involving the 
data elements. 

12. A system of claim 1, including a plurality of 
interface screens which prompt the end user to enter information 
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necessary for developing the information structure of the new data 
collection application. 

13. A system of claim 12 , wherein the first program 
portion permits the user to select fields for data screens, create 
labels and the format for the data screens and define particular 
screen functions. 

14. A system of claim 1, wherein the first program 
portion uses a visual interface with the end user to create an XML 
document . 

15. A system of claim 13, wherein the first program 
portion has the capability of editing data screens in existing data 
collection applications and importing data screens from another data 
collection application available to it for use in the new data 
collection application. 

16. A system of claim 1, wherein the first program 
portion has the capability, of creating new processing rules and 
editing existing processing rules. 

17. A system of claim 16, wherein the rule 
creating /editing capability of the first program portion includes 
the capability of defining how a rule is expressed, creating an 
error message when the expression of the rule is true concerning the 
data, which indicates that the rule has been violated, and defining 
the conditions under which a rule may be overridden. 

18. A system of claim 3, wherein the input data is . in 
the form of data records and the first program portion includes the 
capability of defining compliance characteristics of each input data 
record relative to preselected legal requirements including defining 
questions provided to 'the end-user to determine compliance of the 
data record with the preselected legal requirements. 
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19. A system of claim 1, wherein the input data is in 
the form of data records and wherein the second program portion 
includes the capability of defining compliance characteristics of 
each input data record relative to preselected legal requirements 
including defining questions provided to the end user to determine 
compliance of the data record with the preselected legal 
requirements . 

20. A system of claim 2, wherein the input data is in 
the form of data records and wherein the second program portion 
includes the capability of evaluating input data records against a 
selected matrix specification and selected conditions under which 
the matrix rules can be overridden. 

21. A system of claim 3, wherein the first program 
portion includes the capability of defining the following 
characteristics of the reports: fields, calculations to be 
performed and format. 

22. A system of claim 2, wherein the second program 
portion includes the capability of changing the data elements , the 
data screens and the record-level rules but cannot add new data 
elements or data screens to the information structure. 

23. A system of claim 1, wherein the input data is in 
the form of data records and wherein the second program portion 
includes the capability of creating new data record-level rules and 
field-level rules, and editing existing data record-level rules and 
field-level rules in existing applications, and also includes the 
capability .of defining each rule, applying the rule to the data 
records and displaying an error message when the defined rule is 
true for a data record, which indicates that the rule has been 
violated, and for establishing conditions under which the record- 
level rules and the field-level rules may be overridden. 
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24. A system of claim 3, wherein the second program 
portion includes the capability of creating new matrix information 
and editing existing matrix information, including defining 
conditions under which the matrix rules for evaluating data records 
are overridden. 

25. A system of claim 4, wherein the first program 
portion includes the capability of reviewing all of the information 
provided by the user relative to the information structure and for 
verifying the information structure therefrom. 

26 A system of claim 2, wherein the second program 
portion has the capability of creating new reports for the data 
collection application, editing existing reports and storing said 
reports as metadata. 

27. A system of claim 1, wherein the second program 
portion is located on a server at a site of the end user, while the 
first program portion is at a. site remote from the end user's site. 

28. A software system for developing screens used in a 
new computer program application, which includes obtaining screens 
from another application, including: 

a first software program portion providing an end user an 
opportunity to select a desired screen from another application to 
which the software system has access and' for .importing said desired 
screen for use in the new application, wherein the first program 
portion permits the user to drag the desired screen into a selected 
screen set for the new application; and 

another software program portion which reads . the 
information tables for said desired screen and brings into the new 
application a XML (extensible mark-up language) document associated 
with said desired screen, said another software program portion 
thereafter storing said desired screen and the associated XML 
document in selected information tables for said new application. 
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29 . A system of claim 28 , including means within said 
another software program portion for reading data fields associated 
with said desired screen in said another application and for 
importing and storing substantially all said data fields in the new 
application. 

30. A system of claim 29, wherein said another software 
program portion includes the capability of obtaining processing 
rules and calculations associated with said data field information 
and for importing and storing them into the new application. 

31. A software system for developing an XML document 
associated with a software application comprising: 

a software program portion having an XML capability which 
provides a screen input to a user and permits the user to add a data 
element component to the screen, wherein the first portion includes 
the capability of determining information about said data element 
from an associated dictionary, the first portion including means for 
creating an XML document therefrom which includes selected 
information concerning the form and content of the data element; and 

means for storing the XML document in the associated 
software application. 

32. A system of claim 31, wherein the XML document is 
stored in screen tables in a dictionary portion of the associated 
application. 



33. A system of claim 31, wherein said data document 
information includes look-up codes as well as the size and type of 
the data element. 

34. A system of claim 31, including means for editing 
the XML document after it has been saved in said screens table. 
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